Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9610/000032_owner-urn-ietf _Wed Oct 9 23:30:49 1996.msg

Internet Message Format | 1997-02-19 | 3KB

Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id XAA04919 for urn-ietf-out; Wed, 9 Oct 1996 23:30:49 -0400
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id XAA04914 for <[e-mail]>; Wed, 9 Oct 1996 23:30:46 -0400
Received: from SMTP1.ABRAXIS.COM by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA01971  (mail destined for [e-mail]); Wed, 9 Oct 96 23:30:43 -0400
Received: from [206.155.199.8] by smtp1.abraxis.com (NTMail 3.01.03) id na052299; Wed, 9 Oct 1996 23:34:21 -0400
Message-Id: <[e-mail]>
Date: Wed, 09 Oct 1996 23:35:38 -0400
From: Michael Mealling <[e-mail]>
Organization: Network Solutions
X-Mailer: Mozilla 3.0b7 (X11; I; SunOS 5.5 i86pc)
Mime-Version: 1.0
To: Larry Masinter <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail]
Subject: Re: [URN] advantages of NAPTR over PURLs
References: <96Oct9.195703pdt."2759"@golden.parc.xerox.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
Reply-To: Michael Mealling <[e-mail]>
Errors-To: [e-mail]

Larry Masinter wrote:
>
> > Sorry, but SRV records cannot be used for HTTP without changing all
> > implementations of HTTP. The spec would also need to be changed to
> > say if SRV requests or A requests should occur first, because
> > behavior will differ.
>
> Did SMTP implementations change with the introduction of MX records,
> or was it done at some other level?

Yes. In order to take advantage of MX records ALL implementations of
SMTP had to know to look up that RR instead of just getting the A
record.

>
> > You are not talking abut PURLs as set forth by OCLC. You are
> > talking about something that is halfway between the original Handle
> > proposal and PURLs. The idea of a global resolver (on replicated servers)
> > that would handle all resolution requests was the key feature of the
> > original Handle proposal. It was found unacceptable for several reasons,
> > two of which were:
> >  1) Potential for surgical denial of sevice attacks
>
> You'll have to convince me that NAPTR implementations are less
> succeptable than PURL implementations. Why should that be so? There
> are still replicated services.

Because of two reasons:

a) the root doesn't change very often. Therefore it is cacheable and
therefore doesn't need to be queried.

b) all other queries are to delegated servers. A denial of service
attack can take out one but not ALL of those delegated servers.
Its very difficult if not impossible to cause all DNS server
to just stop working.

This does not take into account the possiblity of corrupting
the records at the root so that everyone goes down a dead-end
path. We hope that DNSSEC will fix that. Or that another
protocol will come along that does this job better than
DNS.

-MM

--
------------------------------------------------------------------------------
Michael Mealling    | 505 Huntmar Park Drive       | Phone:  [phone]
Software Engineer    | Herndon, VA 22070           | Fax:    [phone]
Network Solutions    | <URL:http://www.netsol.com>  | [e-mail]